Content providers generate and sell content but rarely deliver it directly to a buying consumer. Instead, the delivery of the content to a consumer is outsourced to an intermediate party, a content distributor, which is configured to control a content distribution platform comprising one or more content delivery networks (CDNs) for efficiently delivering content to large numbers of users. CDNs are especially suited for delivery of so-called segmented or tiled video content. For example, HTTP adaptive streaming (HAS), Scalable Video Coding (SVC) and spatially segmented video (e.g. tiled video) use segmentation of content on the basis of time, quality and space respectively.
During the segmentation process a so-called manifest file will be generated which describes the relation between the different segment files and/or streams and may also describe the location from where the segments may be retrieved. A manifest file (also known as a Media Presentation Description or MPD for MPEG-DASH or M3U8 playlist for Apple HTTP Live Streaming) may relate to a file comprising segment identifiers identifying segments and their associated location information, e.g. URLs. Segments identified in the manifest file may be retrieved by a file retrieval protocol, e.g. HTTP or FTP. Alternatively, segments identified in the manifest file may be retrieved using a streaming protocol, e.g. RTSP/RTP or HAS. A segment file or segment stream hereafter will be referred to as a segment. Further, a video title, or more in general, a content item deliverable or retrievable through a segmentation scheme (e.g. as described in a manifest file) may be referred to as a segmented content item. In order to enable a client to access a stored segmented content item in a CDN, the client is provided with the manifest file so that it is able to retrieve the segments.
An important responsibility of a content distributor is to make sure that it only delivers content (e.g. a segmented content item) to those users who have obtained the rights to access it. Therefore, when the content distributor receives a request for content from a user, it first validates the request. The process of validating a request for content may include authenticating the request (checking the identity of the requestor) and/or authorizing the request (checking whether the requestor is authorized to access the requested content).
The process of validating requests for content is not only important for the content provider but also for the content distributor, who can only charge the content provider for users who have legitimately accessed the content. One of the risks that a content distributor may face is deep-linking wherein a legitimate user obtains the right to access a single particular content item (e.g. by paying for it), receives information on the location of one or more delivery nodes comprising the content item (e.g. a manifest files comprising URLs of segments) on the basis of an authentication process wherein the user is first authenticated before it receives the manifest file, and wherein such user then (illegally) distributes the content of the manifest file, e.g. the location information, to other non-authorized users (e.g. by placing the full URLs on a website). In that case, when another (unauthorized) user opens (uses) such an URL, such user can then directly request (an retrieve) the content without having paid for it.
In non-HAS scenarios a token-based validation method is known to be used in order to prevent or mitigate threats like deep-linking. Such known token-based validation method uses the concept of a content provider (CP) generating a unique token for each user request for access to a particular content item and then passing such token to the CDN in a redirection process. Whereas such token-based validation has proven to be an effective validation method for validating the purchase of certain content items, deliverable through CDNs to consumers, there are disadvantages when applying it to systems or methods, used for delivering content (items) on the basis of one of the various protocols for the delivery of segmented content, e.g. using an adaptive streaming protocol such as an HTTP-based adaptive streaming (HAS) protocol.
Applying such validation method in an admission control solution for accessing a segmented content item, could be done by using such token-based validation for the initial manifest request (hence for retrieving the manifest file). In this scenario, the initial request for (retrieving/accessing) the segmented content item is sent to the content provider (as in the non-HAS scenario). Upon receiving this request, the content provider redirects the user to the CDN, whereby the content provider inserts a newly generated token in the redirection request. When the CDN receives this token from the user (e.g. the client), it validates it and, after the token is confirmed to be valid (and hence that the request originates from an user that has permission to access the requested content), it sends a manifest file to the client. However, HAS is session-less and—from a HAS supporting CDN perspective—there exists no correlation between one request for (part of a) content (item) and any other (subsequent) request. Therefore the disadvantage of the above solution is that it introduces a new (more advanced) deep-linking vulnerability. Specifically, it introduces the possibility for a malicious user to create a new manifest file in which it points to the “open” non-protected segment URLs on the CDN. This way segments may be directly accessed, thereby circumventing the content provider and the manifest-level token-based validation mechanism.
One solution to the problem of deep-linking manifest files may be the use of an URL obfuscating technique as e.g. used in Microsoft Web Playlists. URL obfuscation replaces the full URL (excluding the FQDN part) in a playlist with a one-time string, which is only valid the first time it is being requested and can only be requested by the same client to which the manifest file was sent. Applying such solution to HAS would however by necessity turn HAS into a state-full protocol, wherein the network has to maintain information about the clients that have been provided with manifest files with obfuscated URLs. Such solution would thus eliminate one of the primary advantages of HAS, i.e. that it is a low-overhead stateless protocol. Another drawback is that it introduces problems for the frequently occurring situation wherein different CDN nodes deliver different segments to the user, since in that case the CDNs need to exchange session information.
Another solution to the problem of deep-linking manifest files is presented in section 3.5.3 of the document draft-brandenburg-cdni-has [http://tools.ietf.org/html/draft-brandenburg-cdni-has-02]. In this solution, the manifest file itself is rewritten by the CDN so that each segment URL in the manifest contains an individual token. In that case however the tokens need to be valid for a long period of time, since a long time period may pass between the creation and delivery of the manifest file and the client requesting the last segments in the manifest file. In practice this would mean that the tokens would have to be valid for at least the duration of the content play-out time, which could be easily be several hours or more. This significantly decreases the level of security provided by the token-based validation, since a malicious user would have plenty of time for distributing the acquired manifest file to other potential users.
Hence, methods and systems are desired which mitigate the risk of abuse of existing token-based validation methods used in the delivery of a segmented content item to a content processing device.